---
title: Overview
hide_title: true
---

# Overview

TF-controller is a controller for Weave GitOps that follows the patterns established
by [Flux](https://fluxcd.io). It is a reliable tool for managing your infrastructure using the GitOps approach.
With its support for Terraform and integration with Weave GitOps,
you can trust that it will help you effectively GitOps-ify your infrastructure and application
resources in the Kubernetes and Terraform universe at your own pace.

The following GitOps models are available to suit your specific needs:

  1. **GitOps Automation Model:** Fully automate the GitOps process for all of your Terraform resources, including the provisioning and enforcement steps.
  2. **Hybrid GitOps Automation Model:** Choose to GitOps-ify certain parts of your existing infrastructure resources, such as a nodegroup or security group in an existing EKS cluster.
  3. **State Enforcement Model:** Use GitOps to enforce an existing `tfstate` without making any other changes.
  4. **Drift Detection Model:** Use GitOps for drift detection, so you can decide what actions to take when a drift occurs.

To get started with TF-controller, simply follow the provided [getting started](../get-started) guide.

## Features

  * **Multi-Tenancy**: TF-controller supports multi-tenancy by running Terraform `plan` and `apply` inside Runner Pods.
    When specifying `.metadata.namespace` and `.spec.serviceAccountName`, the Runner Pod uses the specified ServiceAccount
    and runs inside the specified Namespace. These settings enable the soft multi-tenancy model, which can be used within
    the Flux multi-tenancy setup. _This feature is available since v0.9.0._
  * **GitOps Automation for Terraform**: With setting `.spec.approvePlan=auto`, it allows a `Terraform` object
    to be reconciled and act as the representation of your Terraform resources. The TF-controller uses the spec of
    the `Terraform` object to perform `plan`, `apply` its associated Terraform resources. It then stores
    the `TFSTATE` of the applied resources as a `Secret` inside the Kubernetes cluster. After `.spec.interval` passes,
    the controller performs drift detection to check if there is a drift occurred between your live system,
    and your Terraform resources. If a drift occurs, the plan to fix that drift will be generated and applied automatically.
    _This feature is available since v0.3.0._
  * **Drift detection**: This feature is a part of the GitOps automation feature. The controller detects and fixes drift
    for your infrastructures, based on the Terraform resources and their `TFSTATE`. _This feature is available since v0.5.0._
    * Drift detection is enabled by default. You can use the field `.spec.disableDriftDetection` to disable this behaviour.
      _This feature is available since v0.7.0._
    * The Drift detection only mode, without plan or apply steps, allows you to perform read-only drift detection.
      _This feature is available since v0.8.0._
  * **Plan and Manual Approve**: This feature allows you to separate the `plan`, out of the `apply` step, just like
    the Terraform workflow you are familiar with. A good thing about this is that it is done in a GitOps way. When a plan
    is generated, the controller shows you a message like **'set approvePlan: "plan-main-123" to apply this plan.'**.
    You make change to the field `.spec.approvePlan`, commit and push to tell the TF-controller to apply the plan for you.
    With this GitOps workflow, you can optionally create and push this change to a new branch for your team member to
    review and approve too. _This feature is available since v0.6.0._
  * **YAML-based Terraform**: The `Terraform` object in v0.13.0+ allows you to better configure your
    Terraform resources via YAMLs, but without introducing any extra CRDs to your cluster. Together with a new generator
    called **Tofu-Jet**, we'll now be able to ship pre-generated primitive Terraform modules for all major cloud providers.
    A primitive Terraform module is a module that only contains a single primitive resource, like `aws_iam_role`, or `aws_iam_policy`.
    With this concept, we would be able to use Terraform without writing Terraform codes, and make it more GitOps-friendly at the same time.
    _This feature is available since v0.13.0._
  * **Enterprise Dashboard Support:** with Weave GitOps Enterprise v0.9.6 and later, you are now able to manage `Terraform` objects the same way you can
    with `Kustomization` and `HelmReleases`.
  * **First-class Terraform Cloud Support:** `Terraform` objects can now be configured to use Terraform Cloud as the backend
    for storing the state with `spec.cloud`. _This feature is available since v0.14.0._

## Dependencies

TF-controller has its own versioning system that is separate from the versioning system used by Weave GitOps.
This means that you can install and use TF-controller independently of Weave GitOps and it will not be affected
by the version of Weave GitOps that you are using.

Here is the dependency matrix:

|   Version   | Terraform | Source Controller | Flux v2 |
|:-----------:|:---------:|:-----------------:|:-------:|
| **v0.14.0** |  v1.3.9   |      v0.35.1      | v0.40.x |
|   v0.13.1   |  v1.3.1   |      v0.31.0      | v0.38.x |
